This specification includes appendices A and B, both of which form part of the disclosure. Appendix A includes testscript code for an example business process. Appendix B, which is provided as a microfiche appendix (consisting of 10 sheets with 589 frames), includes user manuals for three commercial implementations (software products) that embody various inventive features.
1. Field of the Invention
The present invention relates to user interfaces and associated methods for testing the functionality of transactional servers.
2. Description of the Related Art
Over the years, computer systems have assumed a growing role in business. Recently, there has been an increase in the use of computers to facilitate business transactions. Transactional servers are computer systems that are used by businesses to automate business processes. For example, a transactional server may be in the form of a web server system that allows customers to access a company""s database, or an SAP system which synchronizes the various aspects of production in a manufacturing plant. As transactional servers assume a greater role in business and become more important to companies, the need to ensure proper operation of the transactional server has also become important. Therefore, the transactional servers and the business applications that run on the transactional servers should be properly tested to ensure reliable operation.
Testing tools that interact with the user interface of the transactional server have been used to test transactional servers. These tools typically involve the use of an interpreter and a test script (xe2x80x9cscriptxe2x80x9d). The interpreter links to a developer interface and sends commands to the developer interface in accordance with the script. The script is commonly a text file written in a particular test language that can be understood by the interpreter. The script is generally written by a test developer (xe2x80x9cdeveloperxe2x80x9d) that is skilled in the particular script language and in general computer programming principles.
The requirements for the script are typically communicated to the developer by a business person who is familiar with the business process to be tested. Using these requirements, the developer writes a script that simulates the actions of one or more users and monitors the responses of the transactional server. Frequently, once the script is run or xe2x80x9cplayed back,xe2x80x9d the developer discovers that the script does not comply with all of the requirements or otherwise does not operate properly. The script must then be revised to correct the defect. The process of revising the script and running it may be repeated several times before the developer is satisfied with the script. The series of steps outlined above is typically repeated for every business process that is tested by the testing tool.
One problem with the above-described method is that it typically occupies a significant amount of time of a skilled programmer. As a result, the process of generating the scripts tends to be expensive. Another problem is that the method does not provide an efficient mechanism for varying the data sets used to test the transactional server; typically, these data sets are hardcoded within script, requiring the script to be edited to use new data sets. Yet another problem is that the testing tools frequently do not provide an efficient mechanism for analyzing the results of the functionality test.
The present invention addresses these and other problems by providing a software-implemented testing tool for generating, running, and viewing the results of tests for testing transactional servers. The various inventive features of the testing tool may be used separately or in combination to test the functionality of a variety of different types of transactional servers. In a preferred embodiment, the testing tool is used to test web-based, SAP-based and mainframe-based servers.
In a preferred embodiment, the testing tool generates tests by recording interactions between a user and the transactional server as the user performs a transaction, such as a business process. For example, in a web-based implementation, the testing tool records interactions between a web browser and a web server, including link selections and form submissions made by the user and pages returned by the server. During or following the recording session, the user can define verification steps to test for expected server responses. For example, the user can define verification steps to test for expected text messages, images, or numerical values within a web page or other screen returned by the transactional server. During execution of the test, which may occur in either an attended or unattended mode, the testing tool xe2x80x9cplays backxe2x80x9d the recorded user steps while monitoring and recording the responses of the transactional server. The results of the test, including the results of the verification steps, are stored for viewing.
One inventive feature of the testing tool involves displaying the test to the user as a hierarchical node structure, such as a tree, in which steps of the test are represented as corresponding nodes. Preferably, each node is displayed as an icon that indicates the type of the step, together with a textual step name or annotation. To edit the test, the user can select a node from the node structure to view and edit the node""s properties. In the preferred embodiment, for example, the user can modify the data input value associated with a data entry step, or modify the verification condition associated with a verification step. The user can also preferably edit the test by performing such actions as dragging-and-dropping and deleting nodes. An important benefit of this feature is that it allows the user to generate and edit tests without the need to know a scripting or other programming language.
Another inventive feature of the testing tool involves the provision of a data table for allowing the user to conveniently specify data sets for running multiple iterations of a test. Using this feature, the user can, for example, record a particular transaction (e.g., looking up and checking the departure time for a particular flight), and then specify additional data sets (e.g., additional flight numbers and expected departure times) to be used to test the transaction. The data table is preferably in the form of a standard-format spreadsheet in which each row corresponds to a single iteration of the test and each column contains the data values to be used with a parameterized step of the test. The use of a spreadsheet for this purpose allows the test author to use standard spreadsheet functions and/or existing spreadsheet data to specify data sets (which may include both input values and expected results) for testing recorded transactions. During execution of the test, the testing tool automatically uses the data sets within the data table to run multiple iterations of the test. The testing tool preferably stores the results of the verification steps in a separate results spreadsheet.
Another inventive aspect of the testing tool involves displaying captured server screens in conjunction with corresponding nodes of the hierarchical node structure to facilitate test editing. When the user selects a node that corresponds to a particular server screen, the testing tool automatically displays the screen to the user (preferably in a separate window). In addition, when the user selects a node that corresponds to a particular screen object (e.g., an input field), the testing tool automatically highlights the object within the screen. The testing tool may also be configured to highlight a node (if any) within the node structure when a user selects a corresponding object within a displayed screen. These features assist the user in identifying the correspondence between particular steps of the test and display elements of the transactional server. The testing tool also preferably displays a context sensitive menu which is dependent upon the type of object (table, field, field, etc.) currently selected in the displayed screen.
Yet another inventive feature of the testing tool involves displaying the results of test execution using a hierarchical node structure (xe2x80x9creport treexe2x80x9d) in which steps of the test are represented by corresponding nodes. When the user selects a node from the report tree, the testing tool automatically displays results (e.g., a returned screen, or results of a verification step) associated with the corresponding step. Results of verification steps are also preferably represented graphically within the report tree, such as by displaying a green check mark or a red xe2x80x9cXxe2x80x9d symbol to indicate pass/fail status. If the test was executed multiple times with different data sets, each iteration is preferably represented within the report tree by a corresponding node (together with a graphical indication of pass/fail status) which can be expanded to view the details of the iteration.